Russ, I realize the RFC 5280 references the 2005 edition of X.509. However the 2009 edition (freely available at http://www.x500standard.com/index.php?n=Ig.LatestAvail ) revises this text again slightly and I think makes the intent even clearer. It states (as part of the main text and no longer a note):

If an extension affects the treatment of the list (e.g., multiple CRLs need to be scanned to examine the entire list of revoked certificates, or an entry may represent a range of certificates), then either that extension or a related extension shall be indicated as critical in the crlExtensions field. Therefore, a critical extension in the crlEntryExtensions field of an entry shall affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. The only example of this situation defined in this Specification is the certificateIssuer CRL entry extension and the related issuingDistributionPoint CRL extension when the indirectCRL Boolean from that extension is set to TRUE.


This is clearly the case for certificateIssuer as you indicate below and as you note below the only other 2 standard crl entry extensions are irrelevant as they can only ever be non-critical and affect only the single identified revoked certificate. Any private extension that might be defined as a crlEntry extension would also have to follow that same rule to be compliant with the base standard. I do believe the 2005 text was clear but offer this 2009 as additional confirmation of the intent (I personally find this text even clearer).

Cheers,
Sharon


From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Thursday, August 23, 2012 4:15 PM
To: Santosh Chokhani
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280

Santosh:


RFC 5280 describes three CRL Entry Extensions, and all of them come from X.509:

            5.3.1.  Reason Code
            5.3.2.  Invalidity Date
            5.3.3.  Certificate Issuer

The first two do not have the concern that you describe, and the third one should only be present if the CRL includes the IssuingDistributionPoint CRL extension, and that extension includes the indirectCRL set to TRUE.  The IssuingDistributionPoint CRL extension must be critical.  RFC 5280 says:

   The issuing distribution point is a critical CRL extension that
   identifies the CRL distribution point and scope for a particular CRL,
   and it indicates whether the CRL covers revocation for end entity
   certificates only, CA certificates only, attribute certificates only,
   or a limited set of reason codes.  Although the extension is
   critical, conforming implementations are not required to support this
   extension.  However, implementations that do not support this
   extension MUST either treat the status of any certificate not listed
   on this CRL as unknown or locate another CRL that does not contain
   any unrecognized critical extensions.

To my mind, the support for the critical IssuingDistributionPoint CRL extension includes the proper support for the Certificate Issuer CRL entry extension.

Russ


On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote:


Russ,

The problem with Denis's proposal is that he wants to replace the text of not using the CRL.

I have cited a specific example in 5280 itself where an entry extension scope goes beyond that of the entry.  It potentially impacts subsequent entries.

Thus, Denis's proposal is unacceptable.  If he just wanted to add the sentence as opposed to replace, it would be fine.

In general, unless 5280 and X.509 stated that an entry extension cannot impact semantics of anything in the CRL other than the entry itself, what you say is unacceptable and potentially insecure.

From: pkix-bounces@ietf.org<mailto:pkix-bounces@ietf.org> [mailto:pkix-bounces@ietf.org]<mailto:[mailto:pkix-bounces@ietf.org]> On Behalf Of Russ Housley
Sent: Thursday, August 23, 2012 3:50 PM
To: denis.pinkas@bull.net<mailto:denis.pinkas@bull.net>
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280


I agree with the proposal that Denis makes.  I support his proposed text.

This validates my text proposal which still is:

   If a CRL contains a critical CRL entry extension that the application
  cannot process, then the application MUST NOT use that CRL entry to
  determine the status of this certificate". :

Russ